1. Field of the Invention
The present invention generally relates to computer software programs, methods, systems and databases used in Financial Service Organizations.
2. Description of the Related Art
FSOs such as banks, credit unions, insurance companies, mutual find companies, credit card companies, brokerage houses, etc., use FSO computer systems to process business transactions. The FSO production systems, which are often referred to as FSO computer systems or FSO systems, are capable of executing application software programs. The application programs may enable FSOs to offer products and services to their clients. The FSO systems may include one or more databases for storing data. The databases may include, for example, groups of data such as the master files of customer account information, transaction-related data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for batch processing.
FSO systems often utilize hardcoded software to process FSO transactions. Changes in the business environment often result in corresponding changes to the processing relationship among various entities of a Financial Service Organization (FSO). For example, new banks being acquired or new branch locations being opened often add to the processing structure of an FSO. FSO systems which utilize hardcoded software may be more difficult to adapt to the changing processing structure.
The following is hereby incorporated by reference: Object Oriented mail server framework mechanism (U.S. Pat. No. 6,081,832), Object Oriented framework mechanism for order processing including predefined extensible classes for defining an order processing environment (U.S. Pat. No. 6,049,665), Object Oriented framework mechanism for determining configuration relations (U.S. Pat. No. 5,937,189), Object Oriented mail server framework mechanism (U.S. Pat. No. 5,768,505).
FSOs such as banks, credit unions, etc., use computer systems running software programs to process FSO transactions. The FSO systems may include one or more databases for storing data. The databases may include groups of data such as the master files of customer account information, transaction data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for batch processing.
FSO systems often utilize hardcoded software to process FSO transactions. Changes in the business environment often result in corresponding changes to the processing relationship among various entities of a Financial Service Organization (FSO). For example, new banks being acquired or new branch locations being opened often add to the processing structure of an FSO. FSO systems, which utilize hardcoded software, become more difficult to adapt to the changing processing structure. For example, it may be difficult to change the format of a hardcoded FSO report that has to be collated by regions, wherein one of the regions has expanded to cover more branch FSOs.
The following is hereby incorporated by reference: Object Oriented mail server framework mechanism (U.S. Pat. No. 6,081,832), Object Oriented framework mechanism for order processing including predefined extensible classes for defining an order processing environment (U.S. Pat. No. 6,049,665), Object Oriented framework mechanism for determining configuration relations (U.S. Pat. No. 5,937,189), Object Oriented mail server framework mechanism (U.S. Pat. No. 5,768,505), Decentralized distributed asynchronous object oriented system and method for electronic data management, storage, and communication (U.S. Pat. No. 5,550,976) and Document display system for organizing and displaying documents as screen objects organized along strand paths (U.S. Pat. No. 5,499,330).
FSOs such as banks, credit unions, etc., use computer systems running software programs to process customer account transactions. The computer systems may include databases for storing data such as the master files of customer account information, transactional data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for later batch processing.
Databases may be used in FSO business transaction processing systems to store, manage and retrieve data for a variety of applications. In many instances, the databases may be extremely large. The contents of the database may often occupy memory space measured in hundred's of gigabytes. When application programs need to access enormous amounts of data on a transactional basis, whether in batch mode or real-time mode, the FSO business transaction processing systems often utilize commercially available database products. One embodiment of a commercially available database product is the DB2 database from International Business Machines (IBM).
Some nomenclature is introduced here to aid in the understanding of terminology used within the FSO business transaction processing system. A trigger is a defined set of actions that are executed when a delete, insert, or update operation is carried out against a specified table in the FSO database. Stored procedures are similar to a trigger. Both consist of procedural logic that is stored at the database level. However, stored procedures are not event-driven and are not attached to a specific table. A stored procedure is explicitly executed by invoking a CALL to the procedure (instead of implicitly being executed like triggers). Additionally, a stored procedure can access many tables without being specifically associated to any of them.
An example of an FSO that may use such a business transaction processing system is a credit card institution. A credit card institution may issue credit cards to customers of the FSO. The credit card institution may also issue credit cards on behalf of client businesses such as department stores. The credit card institution may also acquire and process credit card transactions from customers and client businesses such as department stores. For example, a credit card institution may issue its own credit card. The credit card institution may also have a client department store. The credit card institution may issue a credit card under the department store's name, and may collect and process all credit card transactions for the department store, charging a fee for each transaction processed. Some of the credit card transactions collected by the credit card institution may be for credit cards not issued by the credit card institution. These transactions may be forwarded to the FSO that issued the card. In turn, other FSOs may forward credit card transactions to the credit card institution. Transactions for credit cards issued by the credit card institution may be processed by the credit card institution.
The FSO business transaction processing system may include a data dictionary. A data dictionary may be defined as a collection of descriptions of the data items or elements in the database. For example, the FSO business transaction processing system data dictionary may describe the data elements involved in credit card processing. The data dictionary may describe each of the data elements in the database for credit card processing. Data sets are groups of data, such as master files and transactions, and may be comprised of data elements defined in the data dictionary. Examples of data elements in the FSO data dictionary are customer name, credit card type, and card issuer.
The FSO business transaction processing system may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the data elements in the transaction during processing. An example of a transaction in the FSO system is a credit card transaction. An example of a processing parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction.
The FSO transaction processing application software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The application software program may examine the values of one or more data elements in the transaction data or database master files to determine the value of a processing parameter for the transaction.
The FSO system database may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the data elements in the transaction during processing. An example of a transaction in an FSO system is a credit card transaction. An example of a processing parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction.
An FSO transaction processing software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The software program may examine the values of one or more data elements in the transaction data or master files to determine the value of a processing parameter for the transaction.
In one embodiment, an FSO transaction processing system may process one or more data sets using schedule based processing. The user of the FSO may schedule a period for execution of a processing task for the data set. On meeting the qualifications of the schedule, the scheduled processing tasks would be automatically executed.
In another embodiment, an FSO transaction processing system may processes data sets using random event based processing. The user of the FSO may at random or based on an event request the execution of a processing task for the data set. On meeting the qualifications, the requested processing task would be automatically executed.
In prior art and in one embodiment, the processing of data sets or master files was periodic and ‘account centric’. Application programs in the FSO computer system had to be scheduled to read and evaluate sequentially every record in the data set to determine if one or more processing tasks were to be executed for the record. For example, a data set may contain a list of all account numbers for an FSO. Processing of an account at a pre-determined period, may comprise evaluating conditions to execute for each account number a list of one or more functions or processing tasks. Preferred embodiments of the processing tasks performed on an account number may require the FSO to raise credit limit, change expiration date, send card data for embossing, and others. For example, the FSO may need to extend the expiration date on a group of credit card accounts, which have a current expiration date of December 1999. The application program would sequentially access every record in an account master file and determine which one of the one or more functions or processing tasks is needed to be performed. Each record lacks information that identifies the particular processing task to be performed. This requires that each of the one or more functions or processing tasks must be queried to determine if it is applicable. If master file record matches the specified criteria of having an expiration date of December 1999, then it would execute the processing task that is subsequently found to be applicable i.e. extend the date of expiration of the credit card. If the evaluation criteria did not match then it would go to the next record in the FSO account master file. Assuming a master file has millions of records, and each record may have one or more processing tasks associated with it, the process of sequentially accessing every record to determine applicability of a processing task to a specific record is very inefficient and time consuming. The method also utilizes extensive FSO computer resources to process FSO data sets.
A conventional method to process FSO data sets in a random event based manner, may use a trigger function provided by IBM's DB2 database sub-system. This method limits FSO data set processing to a specified table. Processing of FSO data sets may need a trigger function to access multiple DB2 tables. Another embodiment of prior art, which is also based on IBM's DB2 database sub-system, may use a stored procedure to process FSO data sets. This method has one or more drawbacks, which may limit the usefulness in FSO data set processing applications. Stored procedures are not event driven and must be explicitly initiated by a CALL command in an application program of the FSO computer system.
It is, therefore, desirable to provide a method and a system to identify and execute only those processing tasks for an FSO data set which have been identified to need further processing. The Smart Trigger method and system to process FSO data sets, improves on the trigger and stored procedure methods by removing their drawbacks and uses periodic and event based techniques. The improved method and system is thus more ‘function centric’ and not ‘account centric’.
FSOs such as banks, credit unions, etc., use computer systems running software programs to process customer account transactions. The computer systems may include databases for storing data such as the master files of customer account information, transactional data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for later batch processing.
Databases may be used in FSO business transaction processing systems to store, manage and retrieve data for a variety of applications. In many instances, the databases may be extremely large. The contents of the database may often occupy memory space measured in hundred's of gigabytes. When application programs need to access enormous amounts of data on a transactional basis, whether in batch mode or real-time mode, the FSO business transaction processing systems often utilize commercially available database products. One embodiment of a commercially available database product is the DB2 database from International Business Machines (IBM).
Some nomenclature is introduced here to aid in the understanding of terminology used. A database packageset contains information needed by the FSO database software to locate and access data in the most efficient way for a particular application program in the FSO business transaction processing system. Database packageset switching occurs when the database packageset values associated with one application program are changed to the database packageset values associated with another application program in the same business transaction processing system. Dynamic database packageset switching occurs when the database packageset values associated with one application program are changed in real-time to the database packageset values associated with another application program in the same business transaction processing system. FSO database environmental variables and database registry values may contain information to control a specific database environment within the FSO business transaction processing system. The user may change environmental variables and registry values to change the FSO database environment.
An example of an FSO that may use such a business transaction processing system is a credit card institution. A credit card institution may issue credit cards to customers of the FSO. The credit card institution may also issue credit cards on behalf of client businesses such as department stores. The credit card institution may also acquire and process credit card transactions from customers and client businesses such as department stores. For example, a credit card institution may issue its own credit card. The credit card institution may also have a client department store. The credit card institution may issue a credit card under the department store's name, and may collect and process all credit card transactions for the department store, charging a fee for each transaction processed. Some of the credit card transactions collected by the credit card institution may be for credit cards not issued by the credit card institution. These transactions may be forwarded to the FSO that issued the card. In turn, other FSOs may forward credit card transactions to the credit card institution. Transactions for credit cards issued by the credit card institution may be processed by the credit card institution.
The FSO business transaction processing system may include a data dictionary. A data dictionary may be defined as a collection of descriptions of the data items or elements in the database. For example, the FSO business transaction processing system data dictionary may describe the data elements involved in credit card processing. The data dictionary may describe each of the data elements in the database for credit card processing. Groups of data such as master files and transactions may be comprised of data elements defined in the data dictionary. Examples of data elements in the FSO data dictionary are customer name, credit card type, and card issuer.
The FSO business transaction processing system may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the data elements in the transaction during processing. An example of a transaction in the FSO system is a credit card transaction. An example of a processing parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction. Another example of a processing parameter may be a database identifier, which may point to the location of the data in an FSO database.
The FSO transaction processing application software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The application software program may examine the values of one or more data elements in the transaction data or database master files to determine the value of a processing parameter for the transaction.
A combination of data elements used to determine the value of a processing parameter may be referred to as a key definition for the processing parameter. The combination of data element values constructed from the key definition may be referred to as a key value. For example, a software program for processing credit card transactions for a credit card institution may use the credit card issuer and card type to determine the database identifier.
Key definitions and key value construction are hardcoded in the source code for the FSO system software programs. Modifying the key definitions and the construction of key values from the key definitions involves modifying the source code for all software programs that use the key definitions, recompiling and relinking the programs, reinstalling the software programs, and possibly modifying the data dictionary and database structure used by the software programs. If more than one FSO use the software programs, customization of key definitions and key value construction for one of the FSOs requires creating and maintaining a customized copy of the source code for the programs.
In some FSO systems, processing parameters, such as the database identifier, and the key values used to identify them may be hardcoded in the source code for the FSO system software programs. Modifying the processing parameters and key values for these systems may involve modifying the source code for all software programs that use the processing parameter, recompiling and relinking the programs, and reinstalling the software programs. In other FSO systems, the processing parameters and key values may be stored in the FSO system database. In these systems, the processing parameters and key values in the database and the key definitions and key value construction in the source code must be synchronized. Thus, the processing parameters and key values in the database may be considered hardcoded as well, as they cannot be modified without also modifying the source code and rebuilding the programs as described above.
During the initial design and development phase of a large scale database application, such as the DB2, it may be necessary or desirable to have different database environments such as Development, Quality, Testing, Production, etc. In addition, the Development environment may also be different, based on the operating system of the computer. It may be necessary or desirable to have one or more databases within one environment. For example, it may be desirable to have a separate database for each development engineer within one DB2 Development environment.
Database limitations may prohibit the use of multiple environments within the same database sub-system. The number of multiple databases within one environment within the same database sub-system may also be limited. One embodiment of a database, which may have some of these limitations is the DB2 database from International Business Machines (IBM). These limitations may often substantially reduce the flexibility of the FSO transaction processing application software program to adapt to changing business requirements. For example, an FSO business transaction processing system may need to expand and respond quickly to integrate a newly acquired FSO or process transactions from a new FSO location. A conventional method to implement these changes often involves changing the source code of the application program. This method is programming intensive, time consuming and costly.
The conventional method for the FSO transaction processing application software program developer to work around database environment restriction may be to manually modify the application program source code, in an off-line mode, to change the environment name in the database registry values. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Manual switching between the one or more database environments may often involve a shutdown and startup phase for the database sub-system. This is especially undesirable in installations, which attempt to operate continuously.
The conventional method for the FSO transaction processing application software program developer to avoid the difficulty of adding a new database name may be to add new data to an existing database name. As an alternate, the application software program developer could manually modify the application program source code, in an off-line mode, to change the database name in the DB2 registry values to the ‘new’ database name. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Both of these methods have drawbacks.
The method of adding new data to an existing DB2 database increases the size, often reducing the system performance and increasing maintenance complexity. The method of changing a database name by using applicable commands in the application programming language i.e. by modifying the source code, significantly increases the development time and the costs. For example, adding a new company database in an FSO may affect the source code in thousands of application programs.
FSOs such as banks, credit unions, etc., use computer systems running software programs to process customer account transactions. The computer systems may include databases for storing data such as the master files of customer account information, transactional data such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for later batch processing.
Databases may be used in FSO business transaction processing systems to store, manage and retrieve data for a variety of applications. In many instances, the databases may be extremely large. The contents of the database may often occupy memory space measured in hundred's of gigabytes. When application programs need to access enormous amounts of data on a transactional basis, whether in batch mode or real-time mode, the FSO business transaction processing systems often utilize commercially available database products. One embodiment of a commercially available database product is the DB2 database from International Business Machines (IBM).
Some nomenclature is introduced here to aid in the understanding of terminology used. A database packageset contains information needed by the FSO database software to locate and access data in the most efficient way for a particular application program in the FSO business transaction processing system. Database packageset switching occurs when the database packageset values associated with one application program are changed to the database packageset values associated with another application program in the same business transaction processing system. Dynamic database packageset switching occurs when the database packageset values associated with one application program are changed in real-time to the database packageset values associated with another application program in the same business transaction processing system. FSO database environmental variables and database registry values may contain information to control a specific database environment within the FSO business transaction processing system. The user may change environmental variables and registry values to change the FSO database environment.
An example of an FSO that may use such a business transaction processing system is a credit card institution. A credit card institution may issue credit cards to customers of the FSO. The credit card institution may also issue credit cards on behalf of client businesses such as department stores. The credit card institution may also acquire and process credit card transactions from customers and client businesses such as department stores. For example, a credit card institution may issue its own credit card. The credit card institution may also have a client department store. The credit card institution may issue a credit card under the department store's name, and may collect and process all credit card transactions for the department store, charging a fee for each transaction processed. Some of the credit card transactions collected by the credit card institution may be for credit cards not issued by the credit card institution. These transactions may be forwarded to the FSO that issued the card. In turn, other FSOs may forward credit card transactions to the credit card institution. Transactions for credit cards issued by the credit card institution may be processed by the credit card institution.
The FSO business transaction processing system may include a data dictionary. A data dictionary may be defined as a collection of descriptions of the data items or elements in the database. For example, the FSO business transaction processing system data dictionary may describe the data elements involved in credit card processing. The data dictionary may describe each of the data elements in the database for credit card processing. Groups of data such as master files and transactions may be comprised of data elements defined in the data dictionary. Examples of data elements in the FSO data dictionary are customer name, credit card type, and card issuer.
The FSO business transaction processing system may include processing parameters used in processing transactions. Processing parameters may be used to apply business logic to the data elements in the transaction during processing. An example of a transaction in the FSO system is a credit card transaction. An example of a processing parameter is a transaction price that may be charged to a client of a credit card institution for processing a credit card transaction. Another example of a processing parameter may be a database identifier, which may point to the location of the data in an FSO database.
The FSO transaction processing application software program may use one or more processing parameters while processing a transaction. A processing parameter may have different values for different transactions. The application software program may examine the values of one or more data elements in the transaction data or database master files to determine the value of a processing parameter for the transaction.
A combination of data elements used to determine the value of a processing parameter may be referred to as a key definition for the processing parameter. The combination of data element values constructed from the key definition may be referred to as a key value. For example, a software program for processing credit card transactions for a credit card institution may use the credit card issuer and card type to determine the database identifier.
Key definitions and key value construction are hardcoded in the source code for the FSO system software programs. Modifying the key definitions and the construction of key values from the key definitions involves modifying the source code for all software programs that use the key definitions, recompiling and relinking the programs, reinstalling the software programs, and possibly modifying the data dictionary and database structure used by the software programs. If more than one FSO use the software programs, customization of key definitions and key value construction for one of the FSOs requires creating and maintaining a customized copy of the source code for the programs.
In some FSO systems, processing parameters, such as the database identifier, and the key values used to identify them may be hardcoded in the source code for the FSO system software programs. Modifying the processing parameters and key values for these systems may involve modifying the source code for all software programs that use the processing parameter, recompiling and relinking the programs, and reinstalling the software programs. In other FSO systems, the processing parameters and key values may be stored in the FSO system database. In these systems, the processing parameters and key values in the database and the key definitions and key value construction in the source code must be synchronized. Thus, the processing parameters and key values in the database may be considered hardcoded as well, as they cannot be modified without also modifying the source code and rebuilding the programs as described above.
During the initial design and development phase of a large scale database application, such as the DB2, it may be necessary or desirable to have different database environments for Development, Quality, Testing, Production, etc. In addition, the Development environment may also be different, based on the operating system of the computer. It may be necessary or desirable to have one or more databases within one environment. For example, it may be desirable to have a separate database for each development engineer within one DB2 Development environment.
Database limitations may prohibit the use of multiple environments within the same database sub-system. The number of multiple databases within one environment within the same database sub-system may also be limited. One embodiment of a database, which may have some of these limitations is the DB2 database from International Business Machines (IBM). These limitations may often substantially reduce the flexibility of the FSO transaction processing application software program to adapt to changing business requirements. For example, an FSO business transaction processing system may need to expand and respond quickly to integrate a newly acquired FSO or process transactions from a new FSO location. A conventional method to implement these changes often involves changing the source code of the application program. This method is programming intensive, time consuming and costly.
The conventional method for the FSO transaction processing application software program developer to work around database environment restriction may be to manually modify the application program source code, in an off-line mode, to change the environment name in the database registry values. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Manual switching between the one or more database environments may often involve a shutdown and startup phase for the database sub-system. This is especially undesirable in installations, which attempt to operate continuously. The conventional method for the FSO transaction processing application software program developer to avoid the difficulty of adding a new database name may be to add new data to an existing database name. As an alternate, the application software program developer could manually modify the application program source code, in an off-line mode, to change the database name in the DB2 registry values to the ‘new’ database name. The application source code may be written in higher level programming languages such as COBOL, SQL, C, Visual Basic, C++, Java, and others. Both of these methods have drawbacks.
The method of adding new data to an existing DB2 database increases the size, often reducing the system performance and increasing maintenance complexity. The method of changing a database name by using applicable commands in the application programming language i.e. by modifying the source code, significantly increases the development time and the costs. For example, adding a new company database in an FSO may affect the source code in thousands of application programs.
FSOs such as banks, credit unions, etc., use computer systems running software programs to process FSO transactions. The FSO systems may include one or more databases for storing data. The databases may include groups of data such as the master files of customer account information, transaction data sets such as customer credit card purchase transactions, processing data such as the processing parameters used in processing transactions, and history data such as log files of daily activities for batch processing.
The processing parameters used in the processing of transactions in an FSO system may be embedded in the source code of the FSO system software programs, or the processing parameters may be stored in one or more tables in the FSO system database. Processing parameters may be used to apply business logic to the transactions during processing. A processing parameter may have different values for different transactions based upon one or more attributes of the transactions. For example, the processing parameter values used in processing a customer credit card transaction made at one department store may be different than the processing parameter values used in processing a customer credit card transaction made at a different department store. Attributes of a transaction may be defined by one or more data elements in the transaction or one or more data elements in a master file associated with the transaction. The attributes could be, for example, the name of a bank issuing the credit card to the customer, or the type of credit card (e.g., gold, platinum, etc.). The FSO system may examine the values of one or more data elements (e.g., gold, platinum, etc.) in the transaction data or master files to determine the value of a processing parameter for the transaction. The FSO system may examine the values of one or more data elements in the transaction data or master files to determine the value of a processing parameter for the transaction. A set of data elements useable to determine the value of a processing parameter for a transaction may be referred to as a key definition for the processing parameter. Data element values may be extracted from a transaction data set and an associated master file by using the data elements in the key definition to locate the data element values. The data element values may be combined to form a key value for the processing parameter for the transaction.
Key definitions and the construction of key values are hardcoded in the source code for the FSO system software programs. Modifying the key definitions and the construction of key values from the key definitions involves modifying the source code for all software programs that use the key definitions, recompiling and relinking the programs, reinstalling the software programs, and possibly modifying the data dictionary and database structure used by the software programs. If the software programs are used by more than one FSO, and if one of the FSOs requires customized key definitions, customization of the key definitions and key value construction for one of the FSOs requires creating and maintaining a customized copy of the source code for the software programs.
In some FSO systems, processing parameters and the key values used to identify and select the processing parameters may be hardcoded in the source code for the FSO system software programs. Modifying the processing parameters and key values for these systems may involve modifying the source code for all software programs that use the processing parameters, recompiling and relinking the programs, and reinstalling the software programs. In other FSO systems, the processing parameters and key values may be stored in the FSO system database. In these systems, the processing parameters and key values in the database and the key definitions and key value construction in the source code must be synchronized. Modifying the processing parameters and key values in the database may also require modifying the source code and rebuilding the programs as described above.
As a result of the hardcoding of processing parameters and keys, FSO systems are not flexible in the configuration and use of processing parameters. This inflexibility makes it difficult for the FSO to configure an FSO system to meet custom transaction processing requirements.
The following is, hereby, incorporated by reference: Data retrieval method and apparatus with multiple source capability (U.S. Pat. No. 6,023,694), Graphical user interface for relating key index properties to database table columns (U.S. Pat. No. 5,553,218), Index managing method in database managing system (U.S. Pat. No. 5,806,058) and Relational database management system for chemical structure storage, searching and retrieval (U.S. Pat. No. 5,950,192).
FSOs such as banks, credit unions, etc., use computer systems running software programs to process FSO transactions. The FSO systems may include one or more databases for storing data. The databases may include groups of data such as the master files of customer account information, transaction-related data such as customer credit card purchase transactions, processing-related data such as the processing parameters used in processing transactions including charges to merchants for processing credit card transactions, and history data such as log files of daily activities for batch processing.
The processing parameters used by the FSO system in processing transactions, may be embedded in the source code of the FSO system software programs, or the processing parameters may be stored in one or more tables in the FSO system database. Processing parameters may be used to apply business logic to the transactions during processing. A processing parameter may have different values for different transactions based upon one or more attributes of the transactions. For example, the processing parameter values used in processing a customer credit card transaction made at one department store may be different than the processing parameter values used in processing a customer credit card transaction made at a different department store. Attributes of a transaction may be defined by one or more data elements in the transaction or one or more data elements in a master file associated with the transaction. The attributes could be, for example, the name of a bank issuing the credit card to the customer, or the type of credit card (e.g., gold, platinum, etc.). The FSO system may examine the values of one or more data elements (e.g., gold, platinum, etc.) in the transaction data or master files to determine the value of a processing parameter for the transaction. A set of data elements useable to determine the value of a processing parameter for a transaction may be referred to as a key definition for the processing parameter. Data element values may be extracted from a transaction data set and an associated master file by using the data elements in the key definition to locate the data element values. The data element values may be combined to form a key value for the processing parameter for the transaction. Data elements used in a key definition may be referred to as key elements.
Key definitions and the instructions for constructing or preparing key values are hardcoded in the source code for the FSO system software programs. Modifying the key definitions and the instructions for constructing key values from the key definitions involves modifying the source code for all software programs that use the key definitions and the instructions for constructing the key values, recompiling and relinking the programs, reinstalling the software programs, and possibly modifying a system data dictionary and database structure used by the software programs. If the software programs are used by more than one FSO, and if one of the FSOs requires customized key definitions, customization of the key definitions and instructions for constructing key values for one of the FSOs requires creating and maintaining a customized copy of the source code for the software programs.
In some FSO systems, processing parameters and corresponding key values used to identify and select the processing parameters may be hardcoded in the source code for the FSO system software programs. As an aside, prior FSO systems construct key values and compare the constructed key values to key values embedded in the hardcode in order to find a match. When a match occurs, the corresponding processing parameter is subsequently used in processing the transaction. Modifying the processing parameters and corresponding key values for these systems may involve modifying the source code for all software programs that use the processing parameters, recompiling and relinking the programs, and reinstalling the software programs. In other FSO systems, the processing parameters and corresponding key values may be stored in the FSO system database. In these systems, the processing parameters and corresponding key values in the database must be synchronized with the key definitions and instructions for constructing key values in the source code. Modifying the processing parameters and key values in the database may also require modifying the source code and rebuilding the programs as described above.
As a result of the hardcoding of processing parameters and keys, FSO systems are not flexible in the configuration and use of processing parameters. Any modification to the hardcode must be made by one or more people with sophisticated educational backgrounds and a sufficient understanding of the FSO system. Moreover, the time needed to implement and test modifications to existing FSO systems makes it difficult for FSOs to respond to rapidly changing business strategies.
The following is, hereby, incorporated by reference: Data retrieval method and apparatus with multiple source capability (U.S. Pat. No. 6,023,694), Graphical user interface for relating key index properties to database table columns (U.S. Pat. No. 5,553,218), Index managing method in database managing system (U.S. Pat. No. 5,806,058) and Relational database management system for chemical structure storage, searching and retrieval (U.S. Pat. No. 5,950,192).